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Field of the Invention 

[001] The present invention relates to security mechanisms in 
communication networks. More specifically, the present invention relates to a 
method and an apparatus for authenticating data that is transmitted across a public 
network. 

Related Art 

[002] Dramatic advances in computer technology presently make it 
possible to integrate a significant amount of computing power into small portable 
computing devices, such as cell phones and personal digital assistants (PDAs). 
This has led to a proliferation of networked devices over the past few years. Due 
to a large increase in the number of networked devices, the Internet Protocol 
version 4 (IPv4) address space, which is based on a 32-bit long address format, 
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will soon run out of usable addresses. To solve this problem, Internet Protocol 
version 6 (IPv6) was proposed. IPv6 defines a 128-bit long address format, which 
is believed to provide a sufficient number of addresses to accommodate all 
networked devices. 

5 [003] As larger numbers of devices are able to communicate with each 

other across the Internet, a number of security threats can arise. One issue is the 
address ownership problem: how does one prove that a device legally owns an 
address (i.e., that the device is not stealing an address belonging to another 
device)? 

1 0 [004] A recently proposed Crypto-Based Identifier (CBID) scheme can 

be used to remedy this problem. CBIDs are derived from cryptographic keys. For 
example, a given device in a network can be associated with a unique private- 
public key pair, and the CBID can be derived from the public key. This derivation 
process can involve performing a secure hash on the device's public key and 

15 combining the result of the hash function with the device's network address to 
produce a CBID. As a result, a CBID can be verifiably associated with the 
device's public key and at the same time can contain address information of the 
device. The fact that a CBID contains both identification (i.e., part of the hash of 
the public key) and address information of a device allows one to verify the 

20 device's ownership of the address it is using. 

[005] However, verifying that a device owns an address it is using is not 
sufficient to bootstrap secure communications between end users. The problem 
can be illustrated by the following example: a user Alice uses device A, which is 
connected to the network, and she would like to establish communication with 

25 another user Bob using device B, which is connected to the same network. How 
can Alice be sure that she is communicating with Bob's device and not with any 
other device on the network (although she can be sure that device B legally owns 
the address it is using)? Alice and Bob may be thought of as being at a "cocktail 
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party," where any communications between device A and device B can be 
observed by any other devices at the same party. Moreover, there may be other 
cocktail party participants who are willing to publish their identifiers and to 
eavesdrop on the exchange between Alice and Bob. A malicious user operating a 
5 device, which legally owns the network address it is using, could pretend to be 
Bob and could hijack the traffic from Alice that is intended to go to Bob. 
Consequently, in order to bootstrap secure communications, one needs not only 
address-ownership verification, but also "user authentication," which establishes a 
user's ownership of a device and thereby maps the device to the user. 

1 0 [006] User authentication can be accomplished through the public key 

infrastructure. However, one cannot always assume that the public key 
infrastructure is available. For example, when two users wish to communicate 
with each other through wireless devices, and the area they are located in does not 
have any wireless connectivity to the Internet, neither of the devices can access to 

1 5 an Internet-based public key infrastructure. 

[007] In the absence of a public key infrastructure, an alternative 
approach is to use existing authenticated (but not necessarily secret) human 
communication channels, such as visual or audio communications, to authenticate 
users and to bootstrap secure communications. For example, if Alice wishes to 

20 communicate with Bob through wireless devices in a public place, Alice's device 
needs to identify Bob's device. To achieve this, Bob can verbally communicate to 
Alice his device's address or identifier, which can be represented as a string of 
symbols, and Alice can then enter this string of symbols into her device. 
Although this process can be used to bootstrap secure communications between 

25 wireless devices, having a human enter a string of symbols into a device is a 
tedious and error-prone process, especially with 128-bit long IPv6 addresses. 
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[008] Hence, what is needed is a method and an apparatus for 
authenticating users, in the absence of a public key infrastructure, and without 
requiring a user to enter a long string of symbols. 



5 SUMMARY 

[009] One embodiment of the present invention provides a system that 
facilitates confirmation of data communicated to a first device belonging to a first 
user from a second device belonging to a second user. During operation, the first 
device receives a message containing data from the second device. The first 

10 device then translates the data into a string of words (such as a human-friendly 
representation using a well-known function such as the One Time Password 
(OTP) dictionary defined in IETF RFC 1938) that can be recognized by a human. 
Next, the first device displays the string of words to the first user. The second 
device also translates the original data using the same well-known function. The 

15 first user and the second user then confirm that both strings of words match. The 
confirmation process is performed through a separate communication channel. 
The confirmation ensures that the data sent by the second device is successfully 
received by the first device, is authentic, and is integrity-checked. 

[0010] In a variation of this embodiment, prior to receiving the message, 

20 the first device broadcasts a request asking for the data from the second device. 

[0011] In a variation of this embodiment, the message received by the first 
device is signed with a private key corresponding to a public key associated with 
the second device. In this variation, the system uses the public key associated 
with the second device to verify that the message is signed with the private key 

25 associated with the second device. 

[0012] In a variation of this embodiment, while receiving the message, the 
first device receives more than one message. The first device translates data in the 
other messages into corresponding strings of words which can be recognized by a 
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human, and displays these strings to the first user, thereby allowing the first user 
to match one of these strings of words with the corresponding string derived by 
the second device from the original data. 

[0013] In a variation of this embodiment, prior to the reception of the 
5 message at the first device, the first user obtains a portion of the digest (or 

translation) on a separate communication channel and enters this portion into the 
first device. The first device subsequently uses this portion to filter messages. 

[0014] In a variation of this embodiment, the data received at the first 
device contains a cryptographically generated address (CGA) belonging to the 
10 second device. This CGA is generated by: performing a hash function on the 
second device's public key (or corresponding certificate), and then combining a 
portion of the hash result with a prefix of the devices's IPv6 address. 

[0015] In a variation of this embodiment, the translation uses a one-time 
password (OTP) dictionary. 
1 5 [0016] In a variation of this embodiment, the request includes a CBID 

belonging to the first device, and the request is signed with a private key 
associated with the first device, thereby allowing the request to be verifiably 
associated with the first device. 

20 BRIEF DESCRIPTION OF THE FIGURES 

[0017] FIGs. 1 A and IB illustrate a communication network with multiple 
devices and multiple users, and how a user can be authenticated through a 
separate communication channel in accordance with an embodiment of the present 
invention. 

25 [0018] FIG. 2 presents a flow chart illustrating how a cryptographically 

generated address (CGA) can be derived by performing a hash function on a 
public-key in accordance with an embodiment of the present invention. 
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[0019] FIG. 3 presents a diagram illustrating the process of user 
authentication for bootstrapping secure communications between users in 
accordance with an embodiment of the present invention. 

[0020] FIG. 4 presents a flow chart illustrating how a device can filter 
5 unwanted received messages containing CBIDs in accordance with an 
embodiment of the present invention. 

[0021] FIG. 5 illustrates an example response message format in 
accordance with an embodiment of the present invention. 



10 

DETAILED DESCRIPTION 
[0022] The following description is presented to enable any person skilled 
in the art to make and use the invention, and is provided in the context of a 
particular application and its requirements. Various modifications to the disclosed 

1 5 embodiments will be readily apparent to those skilled in the art, and the general 
principles defined herein may be applied to other embodiments and applications 
without departing from the spirit and scope of the present invention. Thus, the 
present invention is not intended to be limited to the embodiments shown, but is 
to be accorded the widest scope consistent with the principles and features 

20 disclosed herein. 

[0023] The data structures and code described in this detailed description 
are typically stored on a computer readable storage medium, which may be any 
device or medium that can store code and/or data for use by a computer system. 
This includes, but is not limited to, magnetic and optical storage devices such as 

25 disk drives, magnetic tape, CDs (compact discs) and DVDs (digital versatile discs 
or digital video discs), and computer instruction signals embodied in a 
transmission medium (with or without a carrier wave upon which the signals are 
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modulated). For example, the transmission medium may include a 
communications network, such as the Internet. 

User Authentication 
5 [0024] FIG. 1 A illustrates a communication network 1 00 with multiple 

devices and multiple users. A device can include any wired or wireless 
communication device, such as a computer, a PDA, a cell phone, etc. As shown 
in FIG. 1, devices 101, 102, and 103 belong to users 111,1 12, and 1 13, 
respectively. When user 1 1 1 wants to initiate secure communication with user 

10 1 13, user 1 1 1 ideally ensures: (1) that the destination address being used belongs 
to device 103 (the address ownership problem); and (2) that device 103 belongs to 
user 113 (the user authentication problem). 

[0025] The address ownership problem can be addressed by using a CBID 
to map a device's identifier to the public key associated with the device. This 

1 5 mapping relationship provided by the CBID can prove the device's ownership of 
the identifier because the owner of the identifier is the only one who has access to 
the corresponding private key. 

[0026] FIG. IB illustrates how user authentication can be accomplished 
through a separate communication channel. When user 1 1 1 receives device 103's 

20 CBID, which is 128 bit long, user 1 1 1 still needs to confirm that device 103 

belongs to user 113. At this point, device 101 translates the received CBID into a 
string of words that can be recognized by a human, and displays these words to 
user 111. (The translation process can use a One Time Password (OTP) 
dictionary defined in IETF RFC 1938. The OTP dictionary maps any 1 1-bit 

25 number to a human-recognizable word.) Meanwhile, user 113 communicates the 
same string of words, which is translated from device 103's CBID, to user 1 1 1 
through a separate, authenticated human communication channel 120 (e.g., face- 
to-face communication, phone conversation, visual contacts, etc.). User 1 1 1 then 
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compares the words received through channel 120 with the words displayed on 
device 101 . If the two strings match, user 1 1 1 can be confident that user 1 1 1 is 
indeed communicating with a device belonging to user 113. 



5 CBID Construction 

[0027] FIG. 2 presents a flow chart illustrating how a cryptographically 
generated address (CGA) can be derived by performing a hash function on a 
public-key in accordance with an embodiment of the present invention. The 
system first feeds a public-key into a secure hash algorithm (SHA-1), which 
1 0 produces a 1 60-bit result (step 201). A corresponding CBID uses, say, 1 28 bits 
out of that (for example, in an IPv6 ad hoc scenario or in JXTA, the peer-to-peer 
platform). 

[0028] To create a CGA the most-significant 64 bits of the result can be 
used to replace the least-significant 64 bits of the IPv6 address of the device 
15 (step 202). The system then sets the universal/local bit ("u" bit) and the 

individual/group bit ("g" bit) of the IPv6 address to "0", indicating that this is a 
cryptographic IPv6 address (step 203). This modified IPv6 address is then used as 
the CGA of the device (step 204). 



20 Bootstrapping Process 

[0029] FIG. 3 presents a diagram and a corresponding flow chart 
illustrating the process of user authentication for bootstrapping secure 
communications between users in accordance with an embodiment of the present 
invention. Device 101 belonging to user 1 1 1 starts by sending out a broadcast 

25 message to other devices (devices 321, 322, 323, and 103 in this example) 

requesting their CBIDs, wherein the request can contain the CBID of device 101 
and can be signed with the private key of device 101 (step 350). Device 101 then 
receives one or more response messages from a number of devices, including 
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device 103 (step 352). The received messages can be signed with the private keys 
of the sending devices. Note that these response messages can also include 
responses from malicious users trying to impersonate user 113. 

[0030] Next, device 101 translates the received CBIDs into strings of 

5 human-recognizable words using an OTP dictionary (step 354), and displays the 
strings of words to user 1 1 1 (step 356). User 1 1 1 then confirms with user 1 1 3 
(through a separate authenticated communication channel 340) that one string of 
words displayed on device 1 1 1 matches with a string of words translated from 
device 103's CBID (step 358). In this way, user 1 1 1 can confirm that device 103 

10 belongs to user 113. Device 101 then verifies the received messages, which are 
signed with private keys of the sending devices, using the public keys associated 
with the corresponding sending devices (step 360). 

[0031] Note that, during the entire bootstrapping process, there is no need 
for a user to manually enter a 128-bit long CBID, which is a tedious and error- 

1 5 prone process. Instead, the bootstrapping process only requires the user to 

recognize (not enter) words. Note that humans are better suited to recognizing 
words than entering long strings of symbols. 

Message Filtering 

20 [0032] FIG. 4 presents a flow chart illustrating how a device can filter 

unwanted received messages in accordance with an embodiment of the present 
invention. To allow message filtering, user 1 1 1 first obtains from user 113a 
portion (e.g., a number of leading bits) of the CBID (or hash of the data) of device 
103, which belongs to user 113 (step 410). This portion of the CBID can be 

25 represented by words translated with the OTP dictionary to facilitate human 

communications. User 1 1 1 then enters this portion of the CBID into device 101 
(step 420). Device 101 can subsequently use this portion of the CBID to filter out 
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received messages containing CBIDs and can display the filtered messages to user 
111 (step 430). 

Response Message Format 
5 [0033] FIG. 5 illustrates an example response message format in 

accordance with an embodiment of the present invention. A response message 
can contain a device's CBID 501 , a nonce 502, its public key 503, and a digital 
signature 504 of the entire message based on the private key associated with the 
device. Nonce 502 can be a random number previously sent as a challenge in a 

10 request message from a requesting device. By including nonce 502 in the 
response message and signing the message with its private key, a responding 
device allows the requesting device to verify that the responding device signed the 
nonce with the private key, and is not simply replaying an intercepted message 
that was signed with the private key. 

1 5 [0034] The foregoing descriptions of embodiments of the present 

invention have been presented for purposes of illustration and description only. 
They are not intended to be exhaustive or to limit the present invention to the 
forms disclosed. Accordingly, many modifications and variations will be apparent 
to practitioners skilled in the art. Additionally, the above disclosure is not 

20 intended to limit the present invention. The scope of the present invention is 
defined by the appended claims. 
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